In an application server environment, such as that provided in the WebLogic Server (WLS) product from BEA Systems, Inc., network channels, hereafter to referred to as “channels”, are provided to allow external network traffic to be segregated as it arrives or leaves the server. Network channels allow a system administrator to configure additional ports with one or more WebLogic Server instances or clusters (ports in addition to the required Listen Port and SSL Listen Port). A network channel defines the basic attributes for a new network connection to WebLogic Server, including for example:
The protocols the connection supports (HTTP, HTTPS, T3, T3S, COM).
Default listen ports to use for secure and non-secure communication.
Default properties for the connection such as the login timeout value, maximum message sizes, and default user names and passwords.
Whether or not the connection supports tunneling.
Whether the connection can be used to communicate with other WebLogic Servers in the domain, or can be used only for communication with clients.
Channels are configured as distinct entities in the Administration Console, and then one or more channels can be added to servers within the domain. Using a single channel with multiple servers can simplify network configuration for a server domain, because changing the channel configuration automatically changes the connection attributes of all servers that use the channel. Using multiple channels with a single server helps the administrator to segment network traffic by protocol, listen ports, or any other channel configuration property. In a clustered environment, channels also provide the ability to configure clustered server instances on a single NIC, using different port numbers.
After configuring and assigning network channels, the administrator can optionally use channel overrides (also known as network access points) to fine-tune channel settings on an individual server. This includes support for all external protocols; support for connection through NAT firewalls, and support for custom administration channels. This deprecates the requirement for server-level overrides but does not deprecate the usability need for a domain-wide admin port. These channels can be marked exclusively for admin use and there may be more than one of them.
However, all of the above-described features are targeted at channeling external network traffic. Network traffic that is internal to the server is still generally carried over proprietary protocols. However, application server customers are increasingly demanding the ability to also segregate internal network traffic, usually for security or performance reasons. In addition, customers would like to be able to have finer, dynamic, control over external network channels. Accordingly, what is needed is a means for segregating this internal network traffic in a flexible and easily administered manner.